forked from prusa3d/PrusaSlicer
-
-
Notifications
You must be signed in to change notification settings - Fork 520
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a speed knob to the wipe tower. #3569
Open
GurgenCD
wants to merge
90
commits into
supermerill:master
Choose a base branch
from
GurgenCD:wipe_tower_speed_ctrl
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fix createrelease as the mac arm can't be compiled on github anymore
Added a piece of code into handle_legacy to check for aliases. '.mf3 files won't open 2.4.58.3' supermerill#2939
…one click instead of two (recovering the old behavior).
Mitigation: remove shallow angles that seems to make it appear. As the previous remove_colinear was on a fixed dist (taht became too small on long segments) I created a new one that work from an angle. supermerill#2971
And fix for the visualization of the spiral start.
fix refresh for float/&percent fixed ask_for_refresh() for non-bool supermerill#3175
…CE if the extruder name is blank supermerill#3073
(maybe still some quirks for raft with many extruders).
superslicer move from aur to community
The default for wipe_tower_speed is 80mm/s which was hardcoded before. The perimeter and grid section of the wipe tower will also print at wipe_tower_speed. Though before it was hardcoded independently at 60mm/s. wipe_tower_wipe_starting_speed is set to 26mm/s by default. And uses the same ramp up logic as before. Ramping up the speed of the wipe lines with an aggressive curve, before moving linearly 0.8mm/s at a time. wipe_tower_wipe_starting_speed can be turned of by setting to 0. The wipe_tower_speed is capped by the filament_max_volumetric_speed. If filament_max_volumetric_speed is not set (0 value), then there is no cap. I personally only set a filament_max_volumetric_speed on stuff like very flexible TPU and what not. For the rest, I depend on the global volumetric speed limit. This way, I can set the wipe tower speed to exceed my normal printing flow rate since quality of the wipe tower doesn't matter. But a low flow rate filament would still be capped by filament_max_volumetric_speed, preventing a mess. Using bombela@3fbe811
supermerill
pushed a commit
that referenced
this pull request
Apr 25, 2023
The default for wipe_tower_speed is 80mm/s which was hardcoded before. The perimeter and grid section of the wipe tower will also print at wipe_tower_speed. Though before it was hardcoded independently at 60mm/s. wipe_tower_wipe_starting_speed is set to 26mm/s by default. And uses the same ramp up logic as before. Ramping up the speed of the wipe lines with an aggressive curve, before moving linearly 0.8mm/s at a time. wipe_tower_wipe_starting_speed can be turned of by setting to 0. The wipe_tower_speed is capped by the filament_max_volumetric_speed. If filament_max_volumetric_speed is not set (0 value), then there is no cap. I personally only set a filament_max_volumetric_speed on stuff like very flexible TPU and what not. For the rest, I depend on the global volumetric speed limit. This way, I can set the wipe tower speed to exceed my normal printing flow rate since quality of the wipe tower doesn't matter. But a low flow rate filament would still be capped by filament_max_volumetric_speed, preventing a mess. Using bombela@3fbe811 supermerill: * add % for wipe_tower_wipe_starting_speed #3569
merged.
|
Just a message to keep this alive. Would love to see it in SS |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The default for wipe_tower_speed is 80mm/s which was hardcoded before.
The perimeter and grid section of the wipe tower will also print at
wipe_tower_speed. Though before it was hardcoded independently at
60mm/s.
wipe_tower_wipe_starting_speed is set to 26mm/s by default. And uses the
same ramp up logic as before. Ramping up the speed of the wipe lines
with an aggressive curve, before moving linearly 0.8mm/s at a time.
wipe_tower_wipe_starting_speed can be turned of by setting to 0.
The wipe_tower_speed is capped by the filament_max_volumetric_speed.
If filament_max_volumetric_speed is not set (0 value), then there is no
cap.
I personally only set a filament_max_volumetric_speed on stuff like very
flexible TPU and what not. For the rest, I depend on the global
volumetric speed limit. This way, I can set the wipe tower speed to
exceed my normal printing flow rate since quality of the wipe tower
doesn't matter. But a low flow rate filament would still be capped by
filament_max_volumetric_speed, preventing a mess.
I have copied the code from prusa3d#9293 branch of Prusa Slicer, and changed the UI binding to align with how it's processed in SuperSlicer, as well as compiled and tested.